InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0004.txt

Text File | 1993-07-02 | 10.6 KB | 212 lines

Oh boy, are you ready Mark?   Joel King, Ken Bobey and I have been
saving up for a long time.   The ideas are just exploding from us ... so
to speak :-).   Some of this conversation spills over into the realm of
the c-client, so I am also cross posting it to that list as well.

> You raise a number of interesting questions:

He sure did.

> >   1. access to the host's quota control mechanism, where one exists

This was explained quite well.   It's not something we have worried
about a lot, because our sites tend to be disk rich, and the c-client
handled write failures due to space adequately.

> >   2. password changing (for non-Kerberos sites)
>
> I believe that this was going to be considered as part of the Mail Management
> Protocol developed by CMU.  I'd like to hear comments from the CMU hackers on
> this.  I think that an environment in which users do not log into the IMAP
> server as timesharing users will have to have the Mail Management Protocol
> layer; the IMAP-only environment is for the `simple' configurations.

I have been thinking about this a lot!  The whole concept of
authentication is becoming a real issue, but I don't think that it
should be handled in something as application specific as the Message
Management Protocol.  The issue of remote server authentication
obviously extends beyond MUAs.  Any or all distributed applications
require this type of authentication, and current host based
authentication services will not cut it.

The model that we have been working on for the last six months or so was
to develop a true Internet MUA.  IMAP and the c-client go a long way to
realizing that, but do not address the general problem of
authentication.  That is OK, because they were not designed to do so.

To my mind, it should be sufficient for a mail server to provide:

 1.  A message store that an MTA can deliver to.
 2.  A message store that can be accessed via a remote MUA.

It should not be a requirement for a user to have an account on the mail
host just to provide authentication or to identify the user to the MTA
as a potential recipient in the local message store.  Currently of
course, this is not possible because:

1.  The mailhost also performs authentication for the remote MUA
    applications using standard host-based authentication mechanisms.
2.  The current run of MTA's depend on local authentication information
    (the password file) as the routing mechanism for delivery to the
    local message store.

The ideal situation would be to (1) have a host independent repository
for mail application authentication and routing information, and (2) to
have a common interface for both MTAs and MUAs (and all other
distributed applications for that matter) be able to access that host
independent information.

So the question is: where should the authentication and routing
information come from?

A good start for authentication would be to kerberize both the IMAPD
server and the clients.  We have talked about it here, but hadn't gotten
to it yet.  I had also heard a rumour that Mark has considered
kerberizing the c-client - this is a very good idea Mark, and I will
happily volunteer our group to perform this task if you would like.
While kerberos will handle TCP channel authentication well, it does not
appear to me that it is a general enough solution to be useful for
routing to message stores and password management - I may be out
to lunch on the last part of that statement.

I am currently working on a secure access model based on the features of
(watch Mark cringe here), the X.500 directory service - specifically the
QUIPU X.500 implementation provide with the ISODE software.  The
Directory was designed to be a general mechanism for providing
configuration and authentication information to users and applications.
Authentication and security mechanisms comparable to kerberos are
provided via the OSISEC (X.509) and the lightweight directory access
protocols over TCP/IP.

The nice thing about X.500 (and I really don't think that it is
comparable to X.400) is that the authentication information about any
user can be made available to any application in a host independent
manner, but is completely secure from tampering (which cannot
necessarily be said about the host based authentication mechanisms :-).

There is still a fair amount of work to be done to create a practical
application, but it can, and is being done.   I expect that ecs
will have to support a couple of different authentication mechanisms for
now, but I expect that this will be the mechanism of choice in the
future.   I will be producing a paper that describes the concepts in
detail for a conference in late October and will certainly make it
available.

> >   3. forwarding (automatic, i.e. access to '.forward' file or equivalent)
>
> This is also a Mail Management Protocol issue for the same reasons.  CMU???

Agreed, these are absolutely management functions.  Note that most MTAs
perform this function quite well, but once again, make use of host based
account information to do it.  The thing that I am interested in is how
the management protocol is going to work.  We have been told that there
is one in the works, but have heard virtually nothing about it.

It occurred to us early on, that many of the management functions like
asynchronous notification, automatic reply and forwarding and others
(actually the X.400 spec has a good list) required participation by both
the MTA and the MUA.   We thought that the MTA should react to requested
services like forwarding at delivery time (how could the MUA do it ???),
but the MUA should control the service.   That is, the user will request
management functions through the MUA, but some of them will be acted
upon by the MTA.   In fact, if there was a concept of an active (rather
than passive) message store in the Internet model, it should perform
these functions.

We have thought seriously about implementing an active message store,
but have delayed because both the c-client (imapd) and the MTAs *kind
of* implement active message store functions.  Obviously we were getting
into a rats nest.  I don't think that the old BSD flat file message
store is really a good modern solution to this problem though either.

>
> >   4. simple X.500 interface
>
> This is one of those things that everyone talks about a lot, but it isn't all
> that clear to me what it implies.  X.500 is supposed to solve all our problems
> but then again X.400 was supposed to do so too.  I don't think that `simple'
> and `X.anything' properly go together.  We'll need to do something about this,
> but I'm taking a `wait and see' attitude until I understand the issues better.

Well, I have already identified two uses - authentication and routing
configuration information.

The problem with X.500 is not that it is too complicated, it is just
so powerful people seem to have a hard time figuring out how to use it
all at once.   The trick is not to use it all at once, just the
applicable features.

The features that we made use of in authentication and routing can be
thought of in the same vein as Sun's NIS (yellow pages).   In this case
it is application configuration information that is being held and
provided by the directory.   There is little direct user involvement.

There are several other uses that the directory can be put to for MUAs
and MTAs as well.   The most probable is a white pages service - we have
been doing it for some time now.  The idea here is to simply look for
users, organizations, or applications (yes, applications - perhaps a fax
server) that you want to send mail to.

As soon as your network gets any size, it becomes impossible to remember
what Joe in accountings mail address was.  Using a whitepages directory
user agent (DUA) inteface, you can very effectively look up an
individual, and even get a digitized picture and voice sample along with
the information.   Our integration with the MUA at this level is simply
to have the two applications communicate and exchange the relevant
information.   The mail address, full name, and title information for
example can be copied directly into the address field of an outgoing
message, or into a local address book for quick reference in the future.

Another use for the directory is to hold mailing lists - both private
and public.   I guess there are those who will argu that the mailing
list should be held by the local message store (or MTA I guess), but
there is no capability in the message store to provide or restrict
access to this information.   All of these features are provided for
naturally in the directory.   The MTA and MUA just have to be designed
to access the information - this is not difficult to do.   In fact,
routing information in general can be provided by the directory in
exactly the same way as MX record info is provided to MTAs now from DNS.

> >   5. forwarding (user-initiated, i.e. in a session)
>
> Could you explain this?  I don't quite understand what you mean.  Do you mean
> forwarding a message or altering your mail forwarding or ??

I think he wants to forward the message to another address simply by
issuing an IMAP primitive, not by resending through a local smtp MTA.
This is intimately related to the next section, and should be good for a
lengthy debate here.

I am not sure how I feel about this, except to say that it involves the
concept of an active message store entity once again.  I think that
there is some merit to this suggestion - as I said before there are
certain things that really make sense this way.

The thing to do maybe is to define all the things that we would like to
be able to do INDEPENDENT OF THE PROCESS THAT PERFORMS THEM, then try to
assign them to the different roles in a process model.   For example,
just say "we want ot be able to automatically forward mail to another
address", then worry about whether the MUA, MTA or (if there is such a
thing) MS actually performs the function.

> >   6. mail sending
>
> If possible, I would like to see the discussion of this topic take place on
> IETF-REMMAIL and not here.  I am agreeable to letting IMAP follow the
> concensus of the IETF-REMMAIL group, should they achieve closure on the topic.

Hmm ... for new messages I can see no reason for submitting new messages
through the message store, in fact, I can see reasons for not wanting to
do it - and forwarding for that matter as well.  The question merits
discussion however, so I guess I should join this list.   Do you have
some information on how to get onto it.

Cheers all.   I hope that I have stimulated some good discussion, but
have not offended.   It was not my intention to do so.

--
Steve Hole                  Director of Research and Communications
ISA Corporation            mail:  [e-mail]
Edmonton, Alberta, Canada       phone: [phone]